docs: refresh stale architecture and structure docs#4580
Conversation
Update docs/architecture.md and docs/structure.md to match the current implementation: fix component interfaces to match core/interfaces.go, remove the nonexistent Signer/remote-signer component, correct the BFT fault tolerance formula, document the consensus controller and priority protocol, replace outdated DutyDB/ParSigDB data models, refresh the validator API endpoint list, and add a duty lifecycle table and supporting components section. Update the project structure doc with current packages and CLI commands. category: docs ticket: none Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Mention the pluggable consensus controller, correct the Priority and peer discovery descriptions, and add the InclusionChecker. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4580 +/- ##
==========================================
+ Coverage 57.20% 57.22% +0.02%
==========================================
Files 245 245
Lines 33449 33449
==========================================
+ Hits 19135 19142 +7
+ Misses 11890 11880 -10
- Partials 2424 2427 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| @@ -43,11 +52,11 @@ | |||
| - **VC**: `n` physical validator clients (`1` per CN) | |||
| - **PS**: `nxm` physical private shares (`m` per VC, `n` per DV) | |||
There was a problem hiding this comment.
I think this one can be improved as well.
The CV part is being too much under focus.
The BN part can be different and it's good to be reflected in the graph.
The private key shares probably can be portrayed better, that they are in fact partials.
I can make a commit myself for that if fine by you @pinebit .
| *Sign* │ | | ┌──┴─┐ │ | ||
| duty │ | └----─┤VAPI◄───────────────────│── VC | ||
| data │ | └──┬─┘ │ │ Query, sign, submit | ||
| | ├────────────┘ │ | ||
| data │ | └──┬─┘ │ Query, sign, submit |
There was a problem hiding this comment.
This one needs to be fixed as well. VAPI also makes calls to the BN, so it needs the &
| *Sign* │ | | ┌──┴─┐ │ | |
| duty │ | └----─┤VAPI◄───────────────────│── VC | |
| data │ | └──┬─┘ │ │ Query, sign, submit | |
| | ├────────────┘ │ | |
| data │ | └──┬─┘ │ Query, sign, submit | |
| *Sign* │ | | ┌──┴─┐ │ | |
| duty │ | └----─┤VAPI◄───────────────────│── VC | |
| data │ | └&─┬─┘ │ Query, sign, submit |
|
|
||
| Charon core business logic is modeled as a workflow, with a duty being performed in a slot as the “unit of work”. | ||
| ``` | ||
| Core Workflow |
There was a problem hiding this comment.
To be honest, this flow is so vastly different per duty, that I tend to believe it can confuse more the reader / don't give the desired info, rather than be of any help.
The table you've put below that is per duty can probably be expanded to something like this core workflow. I'm thinking of something like - having each of the components lined out beforehand and just putting them together for each duty.
I can make a commit myself for that if fine by you @pinebit .
|
|
||
| - At startup, it submits registrations for all DVs in the cluster (found in cluster-lock.json). | ||
| - Thereafter, it submits registrations in the first slot of every epoch. | ||
| - Thereafter, it submits registrations in the first slot of every epoch (delayed to ~75% into the slot to reduce beacon node load). |
There was a problem hiding this comment.
| - Thereafter, it submits registrations in the first slot of every epoch (delayed to ~75% into the slot to reduce beacon node load). | |
| - Thereafter, it submits registrations in the first slot of every epoch (delayed to ~75% into the slot to capture timeframe with less load on the beacon node). |
| [Get attester duties](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/getAttesterDuties), | ||
| [Get block proposer duties](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/getProposerDuties) |
There was a problem hiding this comment.
We need to reverse those. I thought we did... Not a docs issue though.
Meaning first proposer duties and then attester duties, as that's the order of importance (based on the time in the slot they are executed). We may go to the async route of firing all 3 at once, but I'm cautious doing the 3 request at once will result in resolving proposer duties net slower.
| Duties are not all triggered at the start of the slot. Per the spec, duty types have different | ||
| target offsets into the slot (see [core/scheduler/offset.go](../core/scheduler/offset.go)): | ||
| - `DutyAttester`: 1/3 into the slot | ||
| - `DutyAggregator`: 2/3 into the slot | ||
| - `DutySyncContribution`: 2/3 into the slot | ||
| - Other duties (e.g. `DutyProposer`): at the start of the slot | ||
|
|
There was a problem hiding this comment.
Not really specific for DVs, neither as relevant here. I'd say we can delete that. Or at least put it into other place of the architecture where it's more relevant.
| - *Head events* can trigger early fetching of attestation data as soon as the head block for the slot is known, | ||
| instead of waiting for the 1/3 slot offset (gated by the `fetch_att_on_block` feature flags). The early-fetched | ||
| data is cached by the fetcher via its `FetchOnly` method without triggering the rest of the workflow. | ||
| - *Chain reorg events* invalidate resolved duties (and the fetcher's early-fetched attestation data) since they | ||
| were resolved against a head that may no longer be canonical. |
There was a problem hiding this comment.
Not keen on putting logic that is behind a feature flag in the architecture.
|
|
||
| For `DutyAttester` it [fetches AttestationData](https://github.com/ethereum/beacon-APIs/blob/master/validator-flow.md#/ValidatorRequiredApi/produceAttestationData) from the beacon node. | ||
| For `DutyAttester` it [fetches AttestationData](https://github.com/ethereum/beacon-APIs/blob/master/validator-flow.md#/ValidatorRequiredApi/produceAttestationData) from the beacon node | ||
| (unless already early-fetched via `FetchOnly`, see the scheduler's SSE head event handling above). |
There was a problem hiding this comment.
Again, an unstable yet feature flag logic.
| | `POST /eth/v1/validator/contribution_and_proofs` | `DutySyncContribution`: partial signatures stored in `ParSigDB`. | | ||
| | `POST /eth/v1/validator/prepare_beacon_proposer` | No-op, returns 200 OK (fee recipients are configured by charon from cluster-lock.json). | | ||
| | `GET /eth/v1/node/version` | Returns charon version info. | | ||
| | `GET /eth/v1/events` | Server-sent events stream. | |
There was a problem hiding this comment.
That gives no details. And it's important to do so.
| | `GET /eth/v1/events` | Server-sent events stream. | | |
| | `GET /eth/v1/events` | Wire events to the first beacon node configured in Charon. | |
2 participants
Updates
docs/architecture.md,docs/structure.mdand theCLAUDE.mdarchitecture summary to match the current implementation.docs/architecture.md:Signer/remote-signer component from the workflow diagram (it does not exist in the code) and corrects the BFT fault tolerance note tot = ceil(2n/3)available and honest nodes, toleratingf = floor((n-1)/3)faulty nodes.core/interfaces.go(Scheduler, Fetcher, Consensus + ConsensusController, DutyDB, ValidatorAPI, ParSigDB, SigAgg, AggSigDB, Broadcaster) and notes that file as the source of truth.docs/structure.md:core/encode.go,app/dbindex/,p2p/discovery.go/discv5) and describes relay-based peer discovery.core/consensus,core/tracker,core/priority,core/infosync, app infrastructure libraries, eth2util and testutil subpackages) and the current CLI command tree (combine,exit,deposit,feerecipient,alpha,unsafe).CLAUDE.md:category: docs
ticket: none